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DETAILED ACTION 

Response to Amendment 

1 . In view of applicant's amendment filed on 7/01/09, the status of the application is 
still pending with respect to claims 1-3, 17-28 and 33-36. 



Response to Arguments 

2. Applicant's arguments filed on 7/01/09 have been fully considered but they are 
not persuasive. 

Regarding claims 1, 3 and 24, The applicant argued that the cited art does not 
specifically disclose maintain a local bandwidth management table comprising a local 
token count for each of a plurality of classes of source entities, wherein the source 
entities are application programs (see page 12 of the applicant's remarks). 

The examiner maintains the rejection of claims 1, 2 and 24, wherein Voellm 
shows in fig 3 a table of client side information equivalent to a local bandwidth 
management table, which comprises a local client credit/token count of each client, 
where the client is equivalent to a source entity. Bly is introduced to show that each 
client may have a specified class. In response to the remarks pertaining to the source 
entities being application programs, the examiner notes that no where within the claim is 
this limitation specified (no mention of application programs), and that limitations from 
the specification are not read into the claims. 

The applicant also argued that the cited art does not specifically disclose the 
plurality of load shapers is further configured to request a token for the class of the 
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source entity from the bandwidth management controller in response to the 
transmission, Where Voellm keeps track of transaction requests by a client computer 
rather than software application source entities (see page 12 of the applicants remarks). 

In response to the applicants remarks that Voellm keeps track of transaction 
requests by a client computer rather than software application source entities, the 
examiner notes that no where within the claim is this limitation specified (no mention of 
software application source entities), and that limitations from the specification are not 
read into the claims. Furthermore, Voellm discloses in response to having to send a 
transmission, including a hint (request) from the client (load shaper) and sending this to 
the server (where the rejection of claim 1 shows the server having a management 
system for the credits, see Para 0029 for hint and transmission of such a message). 
The applicant claims in response to the transmission, however the claim does not 
specify what transmission is referred to, where such a transmission can be that from the 
user sending data to the client, where the client receives such information and thus 
performs a transaction. Although Voellm discloses the transmission of this request in 
response to the transmission, Bly is introduced to clarify that a request for credit can be 
performed to a BMC (credit allocation circuit is equivalent to the Server side manager of 
Voellm and the BMC of the current application) in response to the transmission (where 
the claim does not specify what transmission is referred to, therefore the loop existing in 
fig 8 shows that the requesting in element 84 occurs in response to the transmission in 
element 90. 
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Regarding claim 2, 17-23, 25-28, 



The applicant depends on the 



arguments of claims 1 , 3 and 24 for all other claims, so therefore in response, these 
other claims are addressed above. 

Regarding claims 33-36, Newly added claims 33-36 are now addressed below. 



3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 



4. Claims 1,2,3,18,19, 20, 22, 23, 24, 25, 27, 28, 33, are rejected under 34 
U.S.C. 1 03(a) as being unpatentable over Voellm et al. (US 2004/0267932) in view of 
Bly et al. (US 20040042399), hereinafter referred to as Bly. 



each client shapes its load based on credit messages from the server as 
indicated in Para 0031) configured to: 

maintain a local bandwidth management table (fig 3, 320 shows table with 
credits used info) comprising a local token count (fig 3, credits used) for each source 
entities (fig 1, where each client A-C is equivalent to a source entity); 



Claim Rejections - 35 USC § 103 



Regarding claim 1 



Voellm discloses a plurality of load shapers (fig 2, where 
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receive a data packet from a source entity (Para 0029, client receives a new 
request to perform a transaction) transmit the data packet over a multiplexed 
communication path (fig 2, where the clients used the credits that are allocated to 
the connection to send data tot eh buffers of the server, and Para 0021 supports 
an protocol, which includes a multiplexing protocol) if the local token count of the 
source entity is at least one (Para 0026, where the client needs a certain number of 
credits in order to send a request, where the limit cannot be exceeded); and 

decrement the local token count of the source entity in the local bandwidth 
management table in response to the transmission (fig 3, and Para 0026, where the 
credits used are maintained in the table of fig 3, thus a decrement is applied when 
each credit is used to send a request or data); and 

Bandwidth Management Controller (fig 2, server) configured to: 

maintain a centralized bandwidth management table (fig 5 shows an info table) 
comprising a base token count (fig 5, where the combination of credit limits and 
credits used can be manipulated in order to achieve a base token count, and 
furthermore the claim does not define the structure or specification of such a 
count) for each of the plurality of source entities (fig 5, shows info for each client 
source), 

Voellm does not specifically disclose one of the plurality of classes wherein a 
minimum bandwidth is reserved for each of the plurality of classes of source entities and 
the base token count increases at a rate corresponding to the minimum bandwidth; and 
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wherein: the plurality of load shapers is further configured to request a token for the 
class of the source entity from the Bandwidth Management Controller in response to the 
transmission; and the Bandwidth Management Controller is further configured to 
respond to the request if the base token count for the class of the source entity is at 
least one by: providing a token and decrementing the base token count for the class of 
the source entity. 

Bly discloses one of the plurality of classes (Para 0038, high precedence 
versus best effort and Para 0042 for classification of incoming traffic) wherein a 
minimum bandwidth (Para 0039 teaches a minimum amount of credit, where credits 
define the amount of BW ) is reserved for each of the plurality of classes of source 
entities (Para 0042 teaches the queues being classified dependent on the 
classified incoming traffic) and the base token count increases at a rate 
corresponding to the minimum bandwidth (Para 0039, where credits are allocated 
from the burst group allocation table which holds the number of base token 
counts as shown in figs 7 and 8, where the allocation is based on a minimum 
guaranteed BW); and wherein: 

the plurality of load shapers (load shapers are shown within Voellm) is further 
configured to request a token for the class of the source entity (Para 0043 shows 
requesting credit/BW) from the Bandwidth Management Controller (Para 0043, 
request is made to credit allocation circuit which is made equivalent to a BMC 
shown in fig 4) in response to the transmission (fig 8, where a loop exists, thus the 
request of 84 is made after a transmission in 90 as a loop exists); 
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and the Bandwidth Management Controller (fig 3 shows burst group 
allocation 51 equivalent to BMC) further configured to respond to the request (fig 8, 
86 shows response) if the base token count for the class of the source entity is at least 
one by: providing a token (fig 8, burst group assigns credit from burst group 
allocation table and Para 0030 shows that allocation is made only if the allocation 
table has any credits available, thus the amount of credits must be more than 1) 
and decrementing the base token count for the class of the source entity (fig 4 shows 
a burst allocation table which keeps a record of the allocation of burst group, 
therefore when the credits are allocated, this allocation is noted/decremented 
from the bandwidth allocation table). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the client/server credit allocation scheme of Voellm, 
as taught by Bly, since stated in Para 0002-0004 that such a modification would 
improve the lack of scalability, cost per queue for the shaping and the ability to shape 
traffic. 

Regarding claim 2, Voellm does not specifically disclose the centralized 
bandwidth management table further comprises a standby token count for each of the 
plurality of classes of source entities; and the Bandwidth Management Controller is 
further configured to respond to the request if the base token count for the class of the 
source entity is zero and the standby token count for the class of the source entity is at 
least one by: providing a token and decrementing the standby token count for the class 
of the source entity. 
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Bly discloses the centralized bandwidth management table further comprises a 
standby token count for each of the plurality of classes of source entities; and the 
Bandwidth Management Controller is further configured to respond to the request if the 
base token count for the class of the source entity is zero and the standby token count 
for the class of the source entity is at least one by: providing a token and decrementing 
the standby token count for the class of the source entity (Para 0039 discusses unused 
credit which can be made equivalent to standby tokens, i.e. Para 0030 shows that 
request are made to the burst groups/classes, where credits are allocated if the burst 
group has credit to give, therefore one skilled in the art can appreciate that when only 1 
credit remains, this 1 credit is equivalent to a standby token, thus 1 when 1 credit 
remains, 0 base tokens are present and 1 standby token exists). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the client/server credit allocation scheme of Voellm, 
as taught by Bly, since stated in Para 0002-0004 that such a modification would 
improve the lack of scalability, cost per queue for the shaping and the ability to shape 
traffic. 

Regarding claim 3. Voellm discloses a plurality of load shapers (fig 2, where 
each client shapes its load based on credit messages from the server as 
indicated in Para 0031) configured to: 

maintain a local bandwidth management table (fig 3, 320 shows table with 
credits used info) comprising a local token count (fig 3, credits used) for each source 
entities (fig 1, where each client A-C is equivalent to a source entity); 
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receive a data packet from a source entity (Para 0029, client receives a new 
request to perform a transaction) transmit the data packet over a multiplexed 
communication path (fig 2, where the clients used the credits that are allocated to 
the connection to send data tot eh buffers of the server, and Para 0021 supports 
an protocol, which includes a multiplexing protocol) if the local token count of the 
source entity is at least one (Para 0026, where the client needs a certain number of 
credits in order to send a request, where the limit cannot be exceeded); and 

decrement the local token count of the source entity in the local bandwidth 
management table in response to the transmission (fig 3, and Para 0026, where the 
credits used are maintained in the table of fig 3, thus a decrement is applied when 
each credit is used to send a request or data); and 

Bandwidth Management Controller (fig 2, server) configured to: 

maintain a centralized bandwidth management table (fig 5 shows an info table) 
comprising a base token count (fig 5, where the combination of credit limits and 
credits used can be manipulated in order to achieve a base token count, and 
furthermore the claim does not define the structure or specification of such a 
count) for each of the plurality of source entities (fig 5, shows info for each client 
source), 

Voellm does not specifically disclose one of the plurality of classes wherein a 
minimum bandwidth is reserved for each of the plurality of classes of source entities and 
the base token count increases at a rate corresponding to the minimum bandwidth; and 



Application/Control Number: 10/674,977 Page 10 

Art Unit: 2474 

wherein: the plurality of load shapers is further configured to request a token for the 
class of the source entity from the Bandwidth Management Controller in response to the 
transmission; and the Bandwidth Management Controller is further configured to 
respond to the request if the base token count for the class of the source entity is at 
least one by: providing a token and decrementing the base token count for the class of 
the source entity. 

Bly discloses one of the plurality of classes (Para 0038, high precedence 
versus best effort and Para 0042 for classification of incoming traffic) wherein a 
minimum bandwidth (Para 0039 teaches a minimum amount of credit, where credits 
define the amount of BW ) is reserved for each of the plurality of classes of source 
entities (Para 0042 teaches the queues being classified dependent on the 
classified incoming traffic) and the base token count increases at a rate 
corresponding to the minimum bandwidth (Para 0039, where credits are allocated 
from the burst group allocation table which holds the number of base token 
counts as shown in figs 7 and 8, where the allocation is based on a minimum 
guaranteed BW); and wherein: 

the plurality of load shapers (load shapers are shown within Voellm) is further 
configured to request a token for the class of the source entity (Para 0043 shows 
requesting credit/BW) from the Bandwidth Management Controller (Para 0043, 
request is made to credit allocation circuit which is made equivalent to a BMC 
shown in fig 4) in response to the transmission (fig 8, where a loop exists, thus the 
request of 84 is made after a transmission in 90 as a loop exists); 



Application/Control Number: 10/674,977 Page 1 1 

Art Unit: 2474 

and the Bandwidth Management Controller (fig 3 shows burst group 
allocation 51 equivalent to BMC) further configured to respond to the request (fig 8, 
86 shows response) if the base token count for the class of the source entity is at least 
one by: providing a token (fig 8, burst group assigns credit from burst group 
allocation table and Para 0030 shows that allocation is made only if the allocation 
table has any credits available, thus the amount of credits must be more than 1) 
and decrementing the base token count for the class of the source entity (fig 4 shows 
a burst allocation table which keeps a record of the allocation of burst group, 
therefore when the credits are allocated, this allocation is noted/decremented 
from the bandwidth allocation table). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the client/server credit allocation scheme of Voellm, 
as taught by Bly, since stated in Para 0002-0004 that such a modification would 
improve the lack of scalability, cost per queue for the shaping and the ability to shape 
traffic. 

Regarding claim 18. Voellm discloses wherein the local token count for each of 
the plurality of classes of source entities has a maximum count of two tokens (Para 
0028, where the minimum number that can be assigned to the negotiable limit of the 
credits is 2). 

Regarding claim 19, Voellm discloses wherein the plurality of load shapers is 
further configured to maintain a count of outstanding requests for tokens (Para 0026 
shows outstanding transaction requests). 
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Regarding claim 20, Voellm does not specifically disclose the centralized 

bandwidth management table further comprises a standby token count for each of the 
plurality of classes of source entities; and the Bandwidth Management Controller is 
further configured to respond to the request if the base token count for the class of the 
source entity is zero and the standby token count for the class of the source entity is at 
least one by: providing a token and decrementing the standby token count for the class 
of the source entity. 

Bly discloses the centralized bandwidth management table further comprises a 
standby token count for each of the plurality of classes of source entities; and the 
Bandwidth Management Controller is further configured to respond to the request if the 
base token count for the class of the source entity is zero and the standby token count 
for the class of the source entity is at least one by: providing a token and decrementing 
the standby token count for the class of the source entity (Para 0039 discusses unused 
credit which can be made equivalent to standby tokens, i.e. Para 0030 shows that 
request are made to the burst groups/classes, where credits are allocated if the burst 
group has credit to give, therefore one skilled in the art can appreciate that when only 1 
credit remains, this 1 credit is equivalent to a standby token, thus 1 when 1 credit 
remains, 0 base tokens are present and 1 standby token exists). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the client/server credit allocation scheme of Voellm, 
as taught by Bly, since stated in Para 0002-0004 that such a modification would 
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improve the lack of scalability, cost per queue for the shaping and the ability to shape 
traffic. 

Regarding claim 22, Voellm discloses wherein the local token count for each of 
the plurality of classes of source entities has a maximum count of two tokens (Para 
0028, where the minimum number that can be assigned to the negotiable limit of the 
credits is 2). 

Regarding claim 23, Voellm discloses wherein the plurality of load shapers is 
further configured to maintain a count of outstanding requests for tokens (Para 0026 
shows outstanding transaction requests). 

Regarding claim 24. Voellm discloses computer program product and code 

(Para 0016-0020) for performing the functions associated with: 

a plurality of load shapers (fig 2, where each client shapes its load based on 
credit messages from the server as indicated in Para 0031) configured to: 

maintain a local bandwidth management table (fig 3, 320 shows table with 
credits used info) comprising a local token count (fig 3, credits used) for each source 
entities (fig 1, where each client A-C is equivalent to a source entity); 

receive a data packet from a source entity (Para 0029, client receives a new 
request to perform a transaction) transmit the data packet over a multiplexed 
communication path (fig 2, where the clients used the credits that are allocated to 
the connection to send data tot eh buffers of the server, and Para 0021 supports 
an protocol, which includes a multiplexing protocol) if the local token count of the 
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source entity is at least one (Para 0026, where the client needs a certain number of 
credits in order to send a request, where the limit cannot be exceeded); and 

decrement the local token count of the source entity in the local bandwidth 
management table in response to the transmission (fig 3, and Para 0026, where the 
credits used are maintained in the table of fig 3, thus a decrement is applied when 
each credit is used to send a request or data); and 

Bandwidth Management Controller (fig 2, server) configured to: 

maintain a centralized bandwidth management table (fig 5 shows an info table) 
comprising a base token count (fig 5, where the combination of credit limits and 
credits used can be manipulated in order to achieve a base token count, and 
furthermore the claim does not define the structure or specification of such a 
count) for each of the plurality of source entities (fig 5, shows info for each client 
source), 

Voellm does not specifically disclose one of the plurality of classes wherein a 
minimum bandwidth is reserved for each of the plurality of classes of source entities and 
the base token count increases at a rate corresponding to the minimum bandwidth; and 
wherein: the plurality of load shapers is further configured to request a token for the 
class of the source entity from the Bandwidth Management Controller in response to the 
transmission; and the Bandwidth Management Controller is further configured to 
respond to the request if the base token count for the class of the source entity is at 
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least one by: providing a token and decrementing the base token count for the class of 
the source entity. 

Bly discloses one of the plurality of classes (Para 0038, high precedence 
versus best effort and Para 0042 for classification of incoming traffic) wherein a 
minimum bandwidth (Para 0039 teaches a minimum amount of credit, where credits 
define the amount of BW ) is reserved for each of the plurality of classes of source 
entities (Para 0042 teaches the queues being classified dependent on the 
classified incoming traffic) and the base token count increases at a rate 
corresponding to the minimum bandwidth (Para 0039, where credits are allocated 
from the burst group allocation table which holds the number of base token 
counts as shown in figs 7 and 8, where the allocation is based on a minimum 
guaranteed BW); and wherein: 

the plurality of load shapers (load shapers are shown within Voellm) is further 
configured to request a token for the class of the source entity (Para 0043 shows 
requesting credit/BW) from the Bandwidth Management Controller (Para 0043, 
request is made to credit allocation circuit which is made equivalent to a BMC 
shown in fig 4) in response to the transmission (fig 8, where a loop exists, thus the 
request of 84 is made after a transmission in 90 as a loop exists); 

and the Bandwidth Management Controller (fig 3 shows burst group 
allocation 51 equivalent to BMC) further configured to respond to the request (fig 8, 
86 shows response) if the base token count for the class of the source entity is at least 
one by: providing a token (fig 8, burst group assigns credit from burst group 
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allocation table and Para 0030 shows that allocation is made only if the allocation 
table has any credits available, thus the amount of credits must be more than 1) 

and decrementing the base token count for the class of the source entity (fig 4 shows 
a burst allocation table which keeps a record of the allocation of burst group, 
therefore when the credits are allocated, this allocation is noted/decremented 
from the bandwidth allocation table). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the client/server credit allocation scheme of Voellm, 
as taught by Bly, since stated in Para 0002-0004 that such a modification would 
improve the lack of scalability, cost per queue for the shaping and the ability to shape 
traffic. 

Regarding claim 25, Voellm does not specifically disclose the centralized 

bandwidth management table further comprises a standby token count for each of the 
plurality of classes of source entities; and the Bandwidth Management Controller is 
further configured to respond to the request if the base token count for the class of the 
source entity is zero and the standby token count for the class of the source entity is at 
least one by: providing a token and decrementing the standby token count for the class 
of the source entity. 

Bly discloses the centralized bandwidth management table further comprises a 
standby token count for each of the plurality of classes of source entities; and the 
Bandwidth Management Controller is further configured to respond to the request if the 
base token count for the class of the source entity is zero and the standby token count 
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for the class of the source entity is at least one by: providing a token and decrementing 
the standby token count for the class of the source entity (Para 0039 discusses unused 
credit which can be made equivalent to standby tokens, i.e. Para 0030 shows that 
request are made to the burst groups/classes, where credits are allocated if the burst 
group has credit to give, therefore one skilled in the art can appreciate that when only 1 
credit remains, this 1 credit is equivalent to a standby token, thus 1 when 1 credit 
remains, 0 base tokens are present and 1 standby token exists). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the client/server credit allocation scheme of Voellm, 
as taught by Bly, since stated in Para 0002-0004 that such a modification would 
improve the lack of scalability, cost per queue for the shaping and the ability to shape 
traffic. 

Regarding claim 27, Voellm discloses wherein the local token count for each of 
the plurality of classes of source entities has a maximum count of two tokens (Para 
0028, where the minimum number that can be assigned to the negotiable limit of the 
credits is 2). 

Regarding claim 28. Voellm discloses wherein the plurality of load shapers is 
further configured to maintain a count of outstanding requests for tokens (Para 0026 
shows outstanding transaction requests). 

Regarding claim 33, Voellm discloses a plurality of processor units, 

wherein each of said plurality of processor units (fig 1 , see processing unit) is 
associated with a respective one of said plurality of load shapers (fig 1 , where fig 1 is a 
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diagram of the client, where each client of fig 2 has the components including the 
processing unit of fig 1); 

a bus interconnecting each of said plurality of processor units (Para 0018 shows 
that a wired connection can connects the computing devices to one another, where 
such a wired connection is equivalent to a bus); 

a display device (fig 2, each client is accompanied by a monitor for display) 
connected to said plurality of processor units (fig 1 , each client contains processing 
units) and configured to display data from each of said plurality of processor units (Para 
0017 shows that the display of data is well known in the art). 

Regarding claim 34, wherein said method of bandwidth management is 

performed in a multi-processor system comprising a plurality of processor units (fig 1 
and 2 shows that a plurality of client devices exist, where a plurality of clients have 
processing units within); and 

wherein said local bandwidth management table is one of a plurality of local 
bandwidth management tables (see fig 3 for local table) each being associated with a 
respective one of said plurality of processor units (fig 1 , where each processor unit is 
associated with each client, where each client has such a table for storing local info). 

5. Claims 17, 21 and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Voellm et al. (US 2004/0267932) in view of Bly et al. (US 20040042399), 
hereinafter referred to as Bly in view of Jeffries (US 20040062259). 
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Regarding claim 17, The combined teachings of Voellm and Bly do not 

specifically disclose linearly increase the standby token count for each of the plurality of 
classes of source entities when the communication path is not congested; and 
exponentially decrease the standby token count for each of the plurality of source 
entities when the communication path is congested. 

Jeffries discloses linearly increase the standby token count for each of the 
plurality of classes of source entities when the communication path is not congested; 
and exponentially decrease the standby token count for each of the plurality of source 
entities when the communication path is congested (Para 0003 teaches increasing the 
token count continuously, and also decreasing the token count dependent on a 
congestion level). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the combined teachings of Voellm and Bly, since 
stated in Para 0003 that such a modification will avoid adverse conditions by managing 
data packet queues, Where excessive queue lengths are avoided. 

Regarding claim 21, The combined teachings of Voellm and Bly do not 

specifically disclose linearly increase the standby token count for each of the plurality of 
classes of source entities when the communication path is not congested; and 
exponentially decrease the standby token count for each of the plurality of source 
entities when the communication path is congested. 
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Jeffries discloses linearly increase the standby token count for each of the 
plurality of classes of source entities when the communication path is not congested; 
and exponentially decrease the standby token count for each of the plurality of source 
entities when the communication path is congested (Para 0003 teaches increasing the 
token count continuously, and also decreasing the token count dependent on a 
congestion level). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the combined teachings of Voellm and Bly, since 
stated in Para 0003 that such a modification will avoid adverse conditions by managing 
data packet queues, Where excessive queue lengths are avoided. 

Regarding claim 26. The combined teachings of Voellm and Bly do not 

specifically disclose linearly increase the standby token count for each of the plurality of 
classes of source entities when the communication path is not congested; and 
exponentially decrease the standby token count for each of the plurality of source 
entities when the communication path is congested. 

Jeffries discloses linearly increase the standby token count for each of the 
plurality of classes of source entities when the communication path is not congested; 
and exponentially decrease the standby token count for each of the plurality of source 
entities when the communication path is congested (Para 0003 teaches increasing the 
token count continuously, and also decreasing the token count dependent on a 
congestion level). 
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It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the combined teachings of Voellm and Bly, since 
stated in Para 0003 that such a modification will avoid adverse conditions by managing 
data packet queues, Where excessive queue lengths are avoided. 

6. Claims 35 and 36 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Voellm et al. (US 2004/0267932) in view of Bly et al. (US 20040042399) in view of 
Berger et al. (US 5274644), hereinafter referred to as Berger. 

Regarding claim 35, The combined teachings of Voellm and Bly do not 
specifically disclose responding to the request if the base token count for the class of 
the source entity is zero and the standby token count for the class of the source entity is 
at least one by: providing a token and decrementing the standby token count for the 
class of the source entity. 

Berger discloses responding to the request if the base token count for the class 
of the source entity is zero and the standby token count for the class of the source entity 
is at least one by: providing a token and decrementing the standby token count for the 
class of the source entity (Col 7 lines 4560, where if the token bank is empty of credits 
upon a request, a spare bank's credits are requested and issued given that there is 1 or 
more credits available. 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the combined teachings of Voellm and Bly, as taught 
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by Berger, since stated in Col 1 lines 10-15, that such a modification will provide a 
mechanism to fairly and efficiently allocate common resources to multiclass traffic. 

Regarding claim 36, The combined teachings of Voellm and Bly do not 

specifically disclose linearly increasing the standby token count for each of the plurality 
of classes of source entities when the communication path is not congested, and 
exponentially decreasing the standby token count for each of the plurality of source 
entities when the communication path is congested. 

Berger discloses linearly increasing the standby token count for each of the 
plurality of classes of source entities when the communication path is not congested 
(Col 6 lines 10-21 , where the spare bank is filled when the local bank is full, where when 
the local bank is full there is no congestion), and exponentially decreasing the standby 
token count for each of the plurality of source entities when the communication path is 
congested (Col 7 lines 45-60, where the spare bank is decremented when the local 
bank is empty, where the emptying of the local bank indicates that there is congestion 
ass all the credits have been used up). 

It would have been obvious to one of the ordinary skill in the art at the time of the 
invention was disclosed to modify the combined teachings of Voellm and Bly, as taught 
by Berger, since stated in Col 1 lines 10-15, that such a modification will provide a 
mechanism to fairly and efficiently allocate common resources to multiclass traffic. 
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Conclusion 

7. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to CHRISTOPHER P. GREY whose telephone number is 
(571)272-3160. The examiner can normally be reached on 10AM-7:30PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Moe Aung can be reached on (571)272-7314. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Aung S. Moe/ /Christopher P Grey/ 

Supervisory Patent Examiner, Art Unit 2474 Examiner, Art Unit 2474 



